Naming Enhancements for the Internet

The Internet has a number of different namespaces used by its myriad protocols and applications. Unfortunately overloaded naming semantics are creating widespread issues. This position paper reviews the existing namespaces, current naming issues, and then proposes a strawman approach to resolving the current naming issues. 1 Existing Namespaces In the original ARPAnet, the first namespace was the address. The modern Internet primarily uses a 32-bit IPv4 address, for example 128.16.6.8, and experimentally is using the 128-bit IPv6 address. The network-layer address was originally intended for the routing of packets, but currently is misused as a host identifier by upper-layer protocols. Closely associated with the IP address is the IP Subnetwork name, which consists of a routing prefix (up to 32 bits) and a prefix length (ranging from 1 bit to 32 bits) in combination. The IP Subnetwork name is primarily used within routing protocols and the routing system. The upper-layers of the Internet Architecture have additional namespaces. Working our way up the stack, we first encounter the Connection End Point. This is the triple consisting of a host, represented as an IP Address or domain name, a transport-protocol, for example the Transmission Control Protocol (TCP), and a Port number, for example port 25 which is used for electronic mail sent via the Simple Mail Transfer Protocol (SMTP). As we approach the application-layer, we encounter the Domain name, for example cs.ucl.ac.uk, and its derivative the Mailbox name, for example [email protected]. The Mailbox normally names a specific user, though in some cases it names a set of users, for example when the Mailbox names a mailinglist. Alternately, the mailbox might provide a role-based name, for example (postmaster,webmaster)@cs.ucl.ac.uk. So we have overloaded semantics for a mailbox name, which might refer explicitly to a particular human user, other times to a set of users (e.g. mailing list), and yet other times with implicit semantics of a service name (e.g. the user(s) act as the electronic postmaster or webmaster for UCL’s Department of Computer Science). Most recently, the Universal Resource Locator (URL), and its derivatives the Universal Resource Name (URN) and Universal Resource Identifier (URI) have appeared. By now the URL is familiar to nearly everyone, as it is the name used to access web content. If one wanted to read the latest news from cable-TV network CNN, one would use the URL http://www.cnn.com. In this, the first portion, http, names an invocation method, such as the Hyper-Text Transfer Protocol (HTTP), then comes a Domain name (www.cnn.com), and then optionally the name of a specific object associated with that Domain name. The URI and URN differ from the URL in that they name objects without necessarily indicating how to locate the object on the network. In the example above, the domain name has the implicit semantics of a service name. Hence, one can see that we have overloaded semantics, whereby a domain name might sometimes refer to a host, other times to a domain (set of hosts), and yet other times to a service for the specified domain. 2 A Brief History of Naming in the Internet The network-layer address is the most fundamental namespace in a packet network and necessarily existed from the start. However, even early ARPAnet users quickly realised that a more human-friendly name was needed for hosts. This was originally implemented as a flat text file named HOSTS.TXT [Kud74]. At this time there was no concept of a heirarchical Domain name. So, for example, the UCL host attached to the ARPAnet might have been named UCL-SATNET. In the early 1980s, the University of California at Berkeley were developing the Berkeley Software Distribution (BSD) of the AT&T Unix operating system. For the 4.2 BSD release, UCB ported a TCP/IPv4 networking stack into Unix and of course also added the Sockets API to BSD Unix. Because there was no Domain Name System (DNS) at the time, UCB’s Sockets API uses raw IP Addresses rather than supporting Domain names. The Domain Name System (DNS) was deployed in the late 1980s and enhanced the previous host name system in at least two major ways[MD88]. Domain names are explicitly hierarchical, which simplified name administration. Also, the DNS included a protocol used for resolving Domain names into addresses. Since its original deployment, the DNS has been extended with service location capabilities, for example using the MX, KX, or SRV resource records. In modern usage, a Domain name might be used to name a single host, an administrative domain, a service, or even a cluster of servers that are masquerading as a single host. These overloaded semantics make the DNS more complex, and in some ways less useful. Early on, IPv4 addresses had an implicit network mask; by examining the first octet, one could determine which of three classes the network was in and hence which network mask (either 8, 16, or 24 bits) was associated with the address. This inflexibility, combined with ad-hoc address allocation practices led to excessive routing table growth in the early 1990s. This was fixed by the combination of class-less routing, where a variable-length network mask was explicitly specified, and more systematic address allocation policies. For many reasons, including simplified address management and perceived security advantages, Network Address Translation (NAT) has come into common use. 3 Current Naming Issues At first glance, it might appear that the Internet already has a relatively rich set of namespaces. However, there are several significant current issues. The implicit overloading of Domain names to names of services, rather than names of hosts, for example www.cnn.com, creates issues. Also, the current scheme is unable to support multiple instances of a given service (e.g. on different TCP ports) on a single host. There is a clear need to create explicit service